2022-08 New Vision for Station

We want Filecoin Station to be a consumer-oriented desktop application that enables users to contribute their resources to peer-to-peer projects and earn FIL in return.

The ideal UX:

  1. I want to contribute to Filecoin and earn FIL
  1. I download and start Filecoin Station
  1. Done.

We assume that the vast majority of Station users will not be interested in dealing with the complexities of what different Modules are available and how these modules can be configured. The end users are not going to keep up with all the projects ongoing at ProtocolLabs to find out about helping the Network indexer, COD, Saturn, etc. The Station should do that for them.

Our users want to earn FIL, and the less they have to think about it, the better.

If we — by default — manage which modules are installed and run for users, that’s a win-win for everyone:

  1. The Station app is simpler. Reasoning about the app and the app’s behaviour is simpler.
  1. PLN gets more station nodes to deploy to, as their module(s) can be pushed to existing station nodes automatically by us.
  1. Users don’t have to navigate an app store and decide which modules they want to install, run, pause, etc.

The user’s largest concern/worry is going to be performance impact: station impacting usage of their personal device and their internet connection.

Ideally, the Station should ‘do the right thing’, preferably with no user configuration or intervention. We call this mode adaptive cruise control:

  • Aggressively detect CPU usage and back off or throttle off whenever Station may impact the UX. Beyond monitoring CPU usage and system fan usage (on/off), is there any way to measure user-perceived latency?
  • Aggressively detect network congestion and back off or throttle off whenever Station may impact their network-related UX.
  • Similarly, for Memory and Storage.
  • Split the resources between individual Modules in a way that allows the user to earn the most FIL.

We can add user-customizable limits at the Station level too, but these should be advanced features that an average user does not need to know about. We call this cruise control:

  • Don’t run any CPU jobs during certain time frames.
  • Use at most X kbps of bandwidth at a given instant
  • Use at most X GB of RAM or Y GB of disk
  • Store the data & cache files in a non-default location (e.g. on a different drive partition).
  • It’s still the job of the Station to split these resource limits between individual Modules in a way that allows the user to earn the most FIL.

Finally, there is also the option of allowing users to configure resource limits on a per-module basis. We are debating whether this belongs to the Station or whether this is the line after which the users should switch to running individual modules in a standalone way.